
\chapter{总结与展望}
\echapter{Conclusions}

从项目的第一行代码写下到修复已知的最后一个bug且将项目暂时尘封，历时8个月。作为笔者本科阶段工作量最大的项目，它的工作并非简单地设计出工程架构、堆砌业务逻辑，还包括阅读理解大量Linux文档和已有开源库的实现。

\section{总结}{}

本课题所完成的项目是有现实意义的。

本文中的通用服务端网络通信组件包括以下特征和功能：
\begin{enumerate}
	\item 传输层和IP层直接使用Unix域套接字，每个网络线程配合一个epoll对象和多个工作线程以提供并发能力。并提供过载保护。
	\item Http服务器。负责短连接请求。框架已完成Http协议解码与编码。请求包体可用Protobuf序列化数据，以达到相比于传统的xml、json等更高的时间空间效率。
	\item WebSocket服务器。负责长连接请求，提供向自身或（和）其他连接主动推送消息的能力。框架已完成WebSocket协议握手、解码、编码、挥手。
	\item 反向代理。提供转发请求到服务节点、负载均衡的能力。用户可以从多个负载均衡策略中选择。
	\item 传输层模块的代码完全独立于具体的应用层协议，用户可以通过继承通用的应用层协议类，轻易地添加自己的应用层协议。
	\item 框架完全独立于业务，用户可以通过继承相关的业务基类，轻易地添加自己的网络接口。
	\item 用户可使用内置的线程池单例完成自己的异步任务，它可以是：立即型、带序列化标签的立即型、周期型、延时型任务。
\end{enumerate}

图像识别网络模型搭建于ResNet网络，使用图像识别安卓应用程序，用户可以将自己安卓手机上的照片上传给服务端做识别工作，并在较短时间内获取其名称与百科信息。


\section{展望}{}

通用服务端网络通信框架业务无关，独立编译。能帮助有需求的用户实现快速部署自己的业务上服务器。后期本人将继续维护，在web服务器领域努力使它成为C++领域的Tomcat。

在实现通用服务端框架时，我们无法预知上层业务是I/O密集型还是cpu密集型，因此我们只能配置工作线程数为一个折中值。在将来，我们会引入协程机制，在处理I/O密集型的上层业务时，应用层程序员可使用协程的方式取代线程切换。相比与线程切换，协程直接在用户层完成上下文切换，底层框架也不再需要提前评估上层业务来配置工作线程数量。

反向代理模块在保护了应用服务器节点的同时，完成了负载均衡的需求。同时，可作为内网穿透工具，如对于大部分的研究生课题组，服务器性能强但不具有公网IP地址，使用反向代理作为中转节点，可实现让学生随时随地都能访问实验室的服务器的需求。

反向代理此时还只工作在应用层且仅支持Http协议，后期将尝试支持转发长连接协议WebSocket的数据包，且还将尝试使其工作在传输层，直接转发TCP字节流数据，并完善负载均衡的转发策略，努力使之在性能、稳定性上能与Nginx相抗衡。

受限于当前的实验环境——没有真实的生产环境来部署。底层框架的许多问题甚至根本还没有暴露出来，本人将继续长期维护，将它们的问题一一修复。
